Feat/android 17 - #59

Walkthrough

The project updates its Flutter SDK constraint, Android build toolchain, and package dependencies. Android configuration adopts newer Gradle, Kotlin, Java, and SDK versions. Documentation and Android metadata now reference the RepForge repository.

Changes

Toolchain alignment

Repository references

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

@coderabbitai with this auto update tags do we have to remove the kotlin dep from the Buildgradle.kts or similar file ?
android.builtInKotlin
check for the other flag as well

#!/bin/bash
fd build.gradle.kts -a
echo "---app build.gradle.kts---"
cat -n workout-logger/android/app/build.gradle.kts
echo "---settings.gradle.kts---"
cat -n workout-logger/android/settings.gradle.kts
echo "---gradle.properties---"
cat -n workout-logger/android/gradle.properties
echo "---search for kotlin references---"
rg -n "kotlin" workout-logger/android --iglob '*.kts' --iglob '*.properties'

@Devasy, good catch — I dug into this and here's the full picture:

Short answer: no, you don't need to remove the Kotlin plugin from settings.gradle.kts (or anything else) right now. Your current setup is actually correct for where you are in the migration.

Why:

• android.builtInKotlin and android.newDsl are AGP 9.0+ features. Android's own docs state: "You need AGP 9.0 or higher to have built-in Kotlin support."
• This PR only bumps AGP to 8.11.1 (in workout-logger/android/settings.gradle.kts), not to 9.0+.
• I checked Flutter's Gradle plugin source directly (the isBuiltInKotlinEnabled check added in [AGP 9] Support Enabling Built-in Kotlin flutter/flutter#188543). It explicitly does:

  if (agpVersion == null || agpVersion.major < 9) {
      return false
  }

  So with AGP 8.11.1, Flutter's Gradle plugin ignores android.builtInKotlin=true entirely and falls back to auto-applying the legacy kotlin-android (Kotlin Gradle Plugin) itself — exactly like before.
• That auto-apply still needs the org.jetbrains.kotlin.android plugin version to be resolvable, which is why settings.gradle.kts still declares:

  id("org.jetbrains.kotlin.android") version "2.2.20" apply false

  If you remove that declaration now, the build would break because FGP wouldn't be able to resolve/apply the Kotlin plugin version.

So, to summarize both flags:

They were added automatically by the Flutter migrator as forward-looking placeholders, and they don't cause any harm sitting in gradle.properties at 8.11.1. The app/build.gradle.kts comment ("kotlin-android is injected automatically by Flutter's built-in Kotlin support") is slightly misleading right now — technically it's injected by FGP's legacy auto-apply behavior, not true built-in Kotlin, since that isn't active yet.

If you want built-in Kotlin to actually activate, that would require a separate, larger effort: bumping AGP to 9.0+ in settings.gradle.kts, adopting the new DSL (ApplicationExtension/LibraryExtension instead of the android {} block extension functions), and checking plugin compatibility (e.g., android.applicationVariants usage in your app/build.gradle.kts for ABI version codes is part of the legacy variant API and would need migrating too). I'd recommend treating that as a follow-up PR rather than bundling it into this SDK/JDK/Flutter bump.

Let me know if you'd like me to open a follow-up issue to track the AGP 9 / built-in Kotlin migration.

(⁠•‾⁠_⁠•⁠) — curious to see how the AGP 9 migration shakes out when you're ready for it.

Learnt from: Devasy
URL: https://github.com/Devasy/RepForge/pull/59

Timestamp: 2026-07-15T15:47:23.404Z
Learning: In Devasy/RepForge's workout-logger Flutter app (workout-logger/android), `android.builtInKotlin` and `android.newDsl` gradle.properties flags only take effect when AGP >= 9.0.0. Flutter's Gradle plugin (FlutterPluginUtils.isBuiltInKotlinEnabled) explicitly forces built-in Kotlin to false when the detected AGP major version is below 9, falling back to auto-applying the legacy `org.jetbrains.kotlin.android` plugin. The project currently pins AGP to 8.11.1 in workout-logger/android/settings.gradle.kts, so these flags (added automatically by the Flutter migrator) are currently inert placeholders, and the `org.jetbrains.kotlin.android` plugin version declaration in settings.gradle.kts must be kept until an actual AGP 9.0+ upgrade is done.

@coderabbitai nice catch what would be the changes for moving to latest AGP? 9.00 or above, what changes in the gh action would come?

#!/bin/bash
fd -e yml -e yaml . .github/workflows 2>/dev/null
echo "---workflows---"
for f in $(fd -e yml -e yaml . .github/workflows 2>/dev/null); do
  echo "=== $f ==="
  cat -n "$f"
done
echo "---app build.gradle.kts full---"
cat -n workout-logger/android/app/build.gradle.kts
echo "---settings.gradle.kts---"
cat -n workout-logger/android/settings.gradle.kts

@Devasy, here's the breakdown based on the official AGP 9.0.1 release notes and compatibility tables:

1. Version bumps required

Important catch: The official compileSdk/AGP compatibility table lists API level 37 as requiring minimum AGP 9.1.1, not the base 9.0.1. Since this PR already sets compileSdk = 37 / targetSdk = 37 while pinning AGP to 8.11.1, you're technically already ahead of AGP's official support window for that API level (Gradle usually just emits a suppressible warning rather than failing, but worth being aware of). So if/when you move to AGP 9, target 9.1.1+ directly rather than 9.0.1.

2. settings.gradle.kts changes

• Bump com.android.application to 9.1.1+.
• Remove the org.jetbrains.kotlin.android plugin declaration entirely — AGP 9's release notes explicitly state "The org.jetbrains.kotlin.android plugin is not compatible with the new DSL." With android.builtInKotlin=true now actually activating (AGP ≥9), Kotlin compilation is handled internally.

3. app/build.gradle.kts changes

• The android.applicationVariants.configureEach { ... } block used for your ABI-specific versionCodeOverride logic is exactly the deprecated API called out in the AGP 9 migration guide. It must be rewritten using the new androidComponents.onVariants(...) API — this is the biggest actual code change, not just a version bump.
• The kotlinOptions { jvmTarget = ... } block is part of the legacy Kotlin Gradle Plugin DSL; with built-in Kotlin, JVM target config typically moves under kotlin { compilerOptions { jvmTarget = ... } } or an equivalent built-in-Kotlin DSL surface — worth double-checking against Flutter's migration docs once you're actually on AGP 9, since the exact API may still be evolving.
• Any other legacy android {} block usage should still work for now (old classes are deprecated but present) unless you also flip android.newDsl=false as a safety valve during transition — but that would defeat the purpose of adopting android.newDsl=true.

4. Third-party plugin compatibility (the real risk)

• Flutter's flutter-gradle-plugin needs to explicitly support AGP major version 9 (recall: if (agpVersion.major < 9) return false gating built-in Kotlin). AGP 9.0 only shipped in January 2026, so Flutter's stable-channel support maturity for it is worth verifying directly against your target Flutter version (3.44.4 per this PR) before committing to the bump — I don't have high confidence this has been battle-tested yet.
• F-Droid build server compatibility for your signing-block-stripping trick (the comment in app/build.gradle.kts about signingConfig needing to stay on one line) should also be re-verified, since the new DSL/variant API could change how that block is structured internally.

5. GitHub Actions impact

Actually pretty minimal:

• .github/workflows/release.yml already sets java-version: '17' via actions/setup-java@v4 — no change needed there (17 remains AGP 9's minimum too).
• Neither workflow pins a Gradle or AGP version explicitly — both are driven by gradle-wrapper.properties / settings.gradle.kts, so the CI workflow YAML itself likely needs no changes. The version bump is fully contained to the Gradle/AGP config files.
• .github/workflows/test.yml doesn't invoke Gradle/Android build directly (only flutter analyze/flutter test), so it's unaffected either way.

Recommendation

Given the DSL/variant-API rewrite (item 3) and the Flutter-compatibility unknown (item 4), I'd still treat this as a separate, carefully-tested follow-up PR rather than bundling it here. Want me to open a tracking issue for it?

(⁠｀⁠_⁠´⁠) — this one's got some real teeth to it, happy to help scope the follow-up whenever you're ready.

Learnt from: Devasy
URL: https://github.com/Devasy/RepForge/pull/59

Timestamp: 2026-07-15T15:50:48.798Z
Learning: In Devasy/RepForge's workout-logger app (workout-logger/android/app/build.gradle.kts), the ABI-specific versionCode logic uses the legacy `android.applicationVariants.configureEach { ... }` API (casting output to `ApkVariantOutputImpl`) to set `versionCodeOverride` per ABI. This API is deprecated under AGP 9.0's new DSL/variant API model and must be migrated to the `androidComponents.onVariants(...)` API before upgrading AGP to 9.0+. Additionally, the official Android compileSdk/AGP compatibility table lists API level 37 as requiring minimum AGP 9.1.1 (not just 9.0.1), and AGP 9.0 requires minimum Gradle 9.1.0 and removes compatibility with the standalone `org.jetbrains.kotlin.android` plugin (which must be dropped from workout-logger/android/settings.gradle.kts) in favor of built-in Kotlin.

@coderabbitai open a separate issue for this, to be tracked in another pr

#!/bin/bash
set -euo pipefail

repo="Devasy/RepForge"

body=$(cat <<'EOF'
## Summary

Follow-up to `#59`: migrate `workout-logger/android` to Android Gradle Plugin (AGP) 9.0+ to actually activate the `android.builtInKotlin` and `android.newDsl` gradle.properties flags that were added automatically by the Flutter migrator in `#59`. On the current AGP version (8.11.1), these flags are inert placeholders because Flutter's Gradle plugin only enables built-in Kotlin support when AGP major version >= 9.

## Background

- `workout-logger/android/gradle.properties` sets `android.builtInKotlin=true` and `android.newDsl=true`, but Flutter's Gradle plugin (`FlutterPluginUtils.isBuiltInKotlinEnabled`) explicitly forces this to `false` when AGP major version < 9.
- The project currently pins `com.android.application` and `org.jetbrains.kotlin.android` to 8.11.1 / 2.2.20 in `workout-logger/android/settings.gradle.kts`.
- Official AGP compileSdk compatibility tables list API level 37 (already targeted in `#59`) as requiring minimum AGP 9.1.1, not just 9.0.1.

## Required changes

1. **`workout-logger/android/settings.gradle.kts`**
   - Bump `com.android.application` plugin version to `9.1.1`+ (not just `9.0.1`, due to compileSdk 37 compatibility requirements).
   - Remove the `org.jetbrains.kotlin.android` plugin declaration entirely — AGP 9's new DSL is not compatible with the standalone Kotlin Android plugin; built-in Kotlin support handles this instead.

2. **`workout-logger/android/gradle/wrapper/gradle-wrapper.properties`**
   - Bump Gradle distribution to `>= 9.1.0` (AGP 9.0's minimum Gradle requirement).

3. **`workout-logger/android/app/build.gradle.kts`**
   - Rewrite the ABI-specific `versionCodeOverride` logic, currently implemented via the legacy `android.applicationVariants.configureEach { ... }` API (casting output to `ApkVariantOutputImpl`), using the new `androidComponents.onVariants(...)` variant API. This is the biggest non-trivial code change required.
   - Migrate the `kotlinOptions { jvmTarget = ... }` block to the built-in-Kotlin equivalent DSL (e.g., `kotlin { compilerOptions { jvmTarget = ... } }`), verifying against Flutter's built-in Kotlin migration docs at the time of the upgrade.

4. **Compatibility verification (risk items, not pure version bumps)**
   - Confirm Flutter's `flutter-gradle-plugin` (pinned via Flutter SDK `3.44.4`+ per `#59`) has stable-channel support for AGP major version 9 before committing to the bump.
   - Re-verify the F-Droid signing-block-stripping logic in `app/build.gradle.kts` (the comment about `signingConfig` needing to stay on one line) still holds under the new DSL/variant API.

## Affected files

- `workout-logger/android/settings.gradle.kts`
- `workout-logger/android/gradle/wrapper/gradle-wrapper.properties`
- `workout-logger/android/app/build.gradle.kts`
- `workout-logger/android/gradle.properties` (flags already in place from `#59`, will become active)

## Acceptance criteria

- [ ] AGP bumped to `9.1.1`+ in `settings.gradle.kts`, `org.jetbrains.kotlin.android` plugin declaration removed.
- [ ] Gradle wrapper bumped to `>= 9.1.0`.
- [ ] `android.applicationVariants.configureEach` ABI versionCode logic migrated to `androidComponents.onVariants(...)`.
- [ ] `kotlinOptions.jvmTarget` migrated to the built-in-Kotlin equivalent.
- [ ] Flutter Gradle plugin / Flutter SDK version confirmed compatible with AGP 9 on stable channel.
- [ ] F-Droid build (signing block stripping) verified to still work correctly.
- [ ] CI (`.github/workflows/release.yml`, `.github/workflows/test.yml`) confirmed to require no changes (JDK 17 already set via `actions/setup-java@v4`).

## References

- PR: https://github.com/Devasy/RepForge/pull/59
- Discussion: https://github.com/Devasy/RepForge/pull/59#issuecomment (see AGP 9 migration discussion thread)
- Requested by: `@Devasy`
EOF
)

issue_url=$(gh issue create \
  --repo "$repo" \
  --title "Migrate workout-logger/android to AGP 9.0+ for built-in Kotlin / new DSL support" \
  --body "$body" \
  --assignee "Devasy")

echo "Created issue: $issue_url"

@Devasy done — I've opened #60 to track the AGP 9.0+ / built-in Kotlin migration as a follow-up, with the required changes, affected files, and acceptance criteria captured from our discussion. It's assigned to you and links back to this PR.

(⁠｀⁠ヘ⁠´⁠)⁠凸 tracking this properly now — good luck when you tackle it!